Correct coordination of ECA rules by veri cation and control

Event-Condition-Action (ECA) rules are a widely used language for the high level speci cation of controllers in adaptive systems, such as Cyber-Physical Systems and smart environments, where devices equipped with sensors and actuators are controlled according to a set of rules. The evaluation and execution of every ECA rule is considered to be independent from the others, but interactions of rule actions can cause the system behaviors to be unpredictable or unsafe. Typical problems are in redundancy of rules, inconsistencies, circularity, or applicationdependent safety issues. Hence, there is a need for coordination of ECA rule-based systems in order to ensure safety objectives. We propose a tool-supported method for verifying and controlling the correct interactions of rules, relying on formal models related to reactive systems, and Discrete Controller Synthesis (DCS) to generate correct rule controllers. 1 Coordination problems in ECA rules Event-Condition-Action (ECA) rules is de ned in [12] as a set of rules where each of them 'autonomously reacts to actively or passively detected simple or complex events by evaluating a condition or a set of conditions and by executing a reaction whenever the event happens and the condition is true'. The form of the rule is: ON Event IF Condition DO Action. Some characteristics are that: a rule is activated only by events; its execution is autonomous and independent of other rules in the system; it implements a reaction to the incoming event; it contains a guarding condition to execute such actions. Many research work on ECA rules systems are related to active database management systems (ADBMS) [2,13]. Events represent modi cations produced in the database, and ECA rules are used to control it the integrity. But they have also been used in di erent control environments [7] or adaptation frameworks [9], which means that there are many di erent implementations of ECA rule-based systems. The nature of ECA rule-based systems shows several di erent problems in their execution. As described in [17], the most extended problems are redundancy, inconsistency and circularity. Redundancy means that there are two (or more) rules in the system whose functionality is replicated. This can happen in large rule systems where rules are written by di erent persons. An example in a smart home automated system is to have two similar rules : one detects the presence of a person in a room and, if temperature is lower than 15 degrees, then turns on room heaters. The other rule does the same, but also closes the room door. This can be described in ECA syntax as follows (rule numbers are indicated here only for reference, a concrete grammar is described later in Section 3): rule1: ON presence IF (temperature_get < 15) DO heater_on rule2: ON presence IF (temperature_get < 15) DO heater_on, door_close This represents an overload in the rules system in the best of cases, and an undesired repetitive activation of orders on environment devices. Inconsistency occurs when contradictory actions are sent to devices. This can also occur if multiple rules are activated at the same time, and their execution order may render di erent nal states in the system. An example is: lights are activated by the presence of a person in the room, and TV will also be activated. A third rule will turn o the lights then the TV is turned on. rule1: ON presence IF true DO lights_on rule2: ON presence IF true DO TV_on rule3: ON TV_light IF TV_on DO lights_off Depending on the order of execution of rules, the nal state of the system will be di erent. If rules 2 and 3 are activated before rule 1 is executed then the nal state of lights will be di erent than executing rule 1 before rule 3. So the result of the execution of these rules is not predictable. Circularity occurs when rules get activated continuously without reaching a stable system state that makes them nish their execution. Rules can be repeatedly activated without termination condition. Supposing that two lights in a room are programmed with di erent behaviors in mind, the following rules generate a circularity problem: rule1: ON light1_change IF light1_on DO light2_off rule2: ON light1_change IF light1_off DO light2_on rule3: ON light2_change IF light2_on DO light1_on rule4: ON light2_change IF light2_off DO light1_off The rst two rules will try to change the second light to a state di erent from the rst light. The third and fourth rules will try to maintain both lights in the same state. This will continuously generate a continuous circular execution if not detected. Application-speci c issues can be considered additionally in an environment. An example is ordering to open a windows and to turn on the room heaters. It can be considered as a contradiction by the user. In order to know which actions are contradictory, speci c information must be provided about the environment. In this paper we will consider that multiple actions sent to the same device are contradictory. Only one action can be requested to every device at every instant. Coordinating ECA rules is therefore necessary in order to enforce safety properties. One of the problems of ECA rules is that they are considered to be executed independently or autonomously. This means that possible interactions between rules and their e ects are not controlled. In contrast, synchronous reactive languages, used to design and program control systems, provide some characteristics, such as determinism and veri ability [8]. This is useful for the safe execution of control systems. The objective of this work is to provide validation of the ECA rule system before and during the execution of the system, by relating them to synchronous languages. Here, safety is meant for the control system and people in the environment controlled by this control system. The system should not go into undesired states, and controlled devices are considered part this state. Our approach proposed in this paper consists of a model transformation from an ECA rules description to a synchronous programming language. The characteristics of this programming language will be used to validate the set of rules. ECA rule systems are validated, detecting the described issues. Rules execution is also controlled and coordinated to avoid the described problems at run-time. We will concentrate on small or home environment as target systems, although our results are generic enough to be applied in any ECA rule-based system. The Heptagon/BZR programming language [1] is used here to model the ECA rule-based system, including di erent execution policies. This language is used because of its capability to express invariants in the system in the form of contracts, which allows verifying the application by the use of model checking as well as controlling or coordinating the execution of the application according to the described invariants. The following section describes related work to validate or verify ECA rule systems. Section 3 formalizes the ECA models used in this paper. Section 4 shows how ECA rules are translated into a synchronous programming language to pro t of its intrinsic characteristics. Section 5 shows how we perform veri cation and control on rule systems. Finally, in Section 6, we show some conclusions and future works.